…ions

Found via real CI runs: a fresh uv resolution picked social-auth-core
5.0.2 (previously locked at 4.9.1 via pip-compile), which changes the
OAuth pipeline's post-login redirect behavior and breaks
common/djangoapps/third_party_auth's integration test suite (AzureAD,
Google, LinkedIn, Twitter full-pipeline specs all failed the same
assertion in tests/specs/base.py's assert_logged_in_cookie_redirect).

This migration is meant to be a tooling swap, not a dependency
upgrade, so pin back to the 4.x line rather than bundle an
investigation into social-auth-core 5.x's behavior change into this
PR. Mirrors the existing social-auth-app-django<=5.4.1 constraint,
pinned for a related, already-deferred migration in this same
dependency family. Follow-up tracked at
#38841.

Verified: all 46 previously-failing third_party_auth tests pass with
social-auth-core==4.9.1 restored via this constraint.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Rewrites the Makefile's requirements targets, tox.ini, and ~13 CI
workflows to use uv instead of pip-compile/pip-sync for the main app.
Deletes requirements/edx/*.in and *.txt (superseded by pyproject.toml +
uv.lock, added in PR 1 / #38835).

requirements/constraints.txt, common_constraints.txt, and pip-tools.{in,txt}
are intentionally kept for now: requirements/edx-sandbox and scripts/* still
pip-compile against them and aren't migrated until PR 3/4.

requirements/edx/{base,assets,development}.txt are regenerated as `uv
export` compatibility artifacts (via the Makefile's compile-requirements
target) since external tooling -- notably tutor's Dockerfile -- installs
from those exact paths with plain pip, not uv.

check_python_dependencies.yml is disabled (workflow_dispatch only, job
gated with if: false) since find_python_dependencies can't scan
pyproject.toml yet; tracked at openedx/repo-tools#725. User-confirmed
before committing since this removes a CI safety net.

Part of openedx/public-engineering#543 (2 of 5).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Found via real CI runs after opening the PR (unit tests, Quality
Others, and the ReadTheDocs build all failed):

1. Makefile's test-requirements used `uv sync --only-group testing`,
   which EXCLUDES [project.dependencies] entirely (confirmed: `--only-group`
   replaces the dependency set rather than adding to it, unlike `--group`).
   This meant Django, XBlock, and the rest of the actual application were
   never installed for test runs -- ModuleNotFoundError: No module named
   'xblock' on every unit test shard. Fixed to
   `--no-default-groups --group testing`, matching what tox-uv itself
   generates for the equivalent tox environment.

2. .readthedocs.yaml had the same bug in its doc-requirements.txt export
   (`--only-group doc`). Since [project.dependencies] were excluded from
   that export, the subsequent `pip install -e .` resolved the whole
   dependency tree completely unconstrained by uv.lock's
   [tool.uv].constraint-dependencies -- picking setuptools==82.0.1 (violates
   setuptools<82) and Django==6.0.6 (violates Django<6.0). The setuptools
   violation broke fs/pyfilesystem2's pkg_resources import, crashing the
   Sphinx build via Django app loading. Fixed to `--group doc` plus
   `--no-deps` on the `pip install -e .` step, so dependencies only ever
   come from the properly-constrained export.

3. scripts/xsslint_config.py's SKIP_DIRS didn't exclude .venv. Under the
   old pip-compile system, dependencies installed into the system Python
   outside the repo checkout, so this never mattered. Now that `uv sync`
   creates .venv/ inside the checkout, xsslint's directory walk (which
   defaults to scanning the whole cwd) swept up thousands of vendored
   third-party files, inflating violations from 64 (the accepted baseline)
   to 316.

Verified all three: real pytest run (59 passed) plus full Django
`manage.py check` for both LMS and CMS against the corrected
test-requirements; a local simulation of the RTD build job sequence
confirms Django==5.2.15/setuptools==81.0.0 (both constraint-compliant)
and a successful Sphinx build.

Audited every other `--only-group` usage introduced in this migration
(assets.txt compat export, semgrep.yml) -- both are intentionally
project-dependency-free, matching the original files' documented
behavior, and their CI checks already passed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

requirements/edx/{base,development}.txt were regenerated from the
uv.lock that predated PR 1's social-auth-core<5.0.0 constraint, so
they still referenced social-auth-core==5.0.2 -- caught by
check-consistent-dependencies.yml's re-run of `make compile-requirements`.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Gives requirements/edx-sandbox/ its own standalone pyproject.toml +
uv.lock, independent of the main app's dependency graph (codejail
intentionally runs untrusted code in a separate, isolated venv).

[tool.edx_lint].uv_constraints holds only the subset of the root
constraints relevant to this environment's deps (numpy, lxml,
setuptools) -- uv/edx-lint have no cross-project constraint chaining
equivalent to pip-compile's "-c ../constraints.txt", so root and
sandbox constraints are now independently maintained (documented in
requirements/edx-sandbox/README.rst).

base.txt is regenerated as a `uv export` compatibility artifact (the
README documents it as a supported, if unstable, direct pip-install
target). releases/*.txt are untouched -- they're frozen historical
snapshots, not part of any active compile loop; README now documents
cutting future ones via `uv export` instead of pip-compile.

Part of openedx/public-engineering#543 (3 of 5).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…on 4/5)

Gives scripts/xblock, scripts/user_retirement, and scripts/structures_pruning
each their own standalone pyproject.toml + uv.lock, mirroring the
codejail sandbox pattern from PR 3. structures_pruning's local
[tool.edx_lint].uv_constraints keeps the pymongo<4.4.1 pin it inherited
via the old "-c ../../../requirements/constraints.txt" chain.

These scripts are documented (in their own READMEs) to support git
sparse-checkout usage -- cloning only e.g. scripts/user_retirement/
without the rest of edx-platform. A self-contained pyproject.toml is
actually an improvement here over the old relative "-c
../../../requirements/constraints.txt" reference, which wouldn't even
resolve in a sparse checkout that excludes the root requirements/ dir.

Compatibility .txt exports are kept at their previously-documented
paths (e.g. scripts/user_retirement/requirements/{base,testing}.txt)
since each script's own README explicitly instructs `pip install -r`
against those exact paths.

Also fixes check-consistent-dependencies.yml's path filter and the two
PR-creating workflows' add-paths, neither of which would have picked
up changes to the new scripts/*/pyproject.toml or uv.lock files.

Part of openedx/public-engineering#543 (4 of 5).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Deletes requirements/constraints.txt, common_constraints.txt, and
pip-tools.{in,txt} -- these were kept alive through PR 2-4 because
requirements/edx-sandbox and scripts/* still pip-compiled against
them, but PR 4 was the last consumer, so they're now fully unused.

Removes the correspondingly-vestigial Makefile machinery: the
pre-requirements target, the COMMON_CONSTRAINTS_TXT curl-fetch-and-sed
target, and the CUSTOM_COMPILE_COMMAND/COMPILE_OPTS variables that only
existed to feed pip-compile invocations which no longer exist anywhere
in this repo.

Finalizes requirements/README.rst for the fully-migrated state and
fixes a couple of remaining stale references (constraints.txt ->
[tool.edx_lint].uv_constraints).

This is the last of 5 PRs migrating openedx-platform from pip-compile
to uv + PEP 621/735 pyproject.toml, tracked in
openedx/public-engineering#543. Two follow-up
items remain outside this repo's control:
- openedx/repo-tools#725: find_python_dependencies needs pyproject.toml
  support before check_python_dependencies.yml can be re-enabled.
- Tutor's Dockerfile installs from requirements/edx/{base,assets,development}.txt
  with plain pip; those are kept as `uv export` compatibility artifacts
  (see PR 2 / #38836) rather than deleted, so no action is required there,
  but tutor maintainers should be aware these are now generated files.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CI's "Compile requirements" check re-runs `make compile-requirements`
and fails if it produces any diff, to catch exactly this kind of
inconsistency. The compat-export files in this PR were originally
generated with uv 0.11.26; a newer uv (0.11.30, matching what
astral-sh/setup-uv installs in CI) resolves grpcio/grpcio-status with
an explicit `; platform_python_implementation != 'PyPy'` marker that
0.11.26 omitted. Regenerated with uv 0.11.30 to match.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

The uv migration for scripts/user_retirement dropped the lxml pin that
requirements/constraints.txt previously carried, letting the lockfile
resolve to lxml 6.1.1. The pin exists to avoid a libxml2 version
mismatch at runtime (#36695), and this script
transitively depends on lxml via simple-salesforce -> zeep, so the
same pin applies here as it does at the repo root.

- bundled -> non-core: clearer name for the "installed-by-default but
  not required to run/test" group (matches the in-file comment wording).
- dev -> default: avoids near-duplicate naming with the development
  group it wraps. Explicitly set tool.uv.default-groups = ["default"]
  to preserve bare `uv sync`'s existing behavior of installing this
  group, since renaming away from uv's built-in "dev" default name
  would otherwise silently stop that.
- Verified both renames are lockfile/export no-ops: uv.lock package
  versions are byte-identical (diff is metadata-only), and the
  regenerated requirements/edx/{base,development}.txt compat exports
  only changed in their header comments.
- Verified the assets group's minimal uv sync actually functionally
  compiles Sass (not just installs packages): confirmed libsass's
  _sass.compile_filename binding compiles real .scss to .css from that
  minimal 4-package environment. The one compile failure encountered
  (missing edx-bootstrap import) is from node_modules/npm, a separate
  toolchain untouched by this dependency-group split -- documented in
  the script's docstring.

…migration-consolidated

# Conflicts:
#	requirements/constraints.txt
#	requirements/edx/base.txt
#	requirements/edx/development.txt
#	requirements/edx/doc.txt
#	requirements/edx/testing.txt

Merged master (bringing in automated Python dependency-upgrade PRs
#38926/#38927), which required resolving modify/delete conflicts on
the legacy pip-compile files this PR already deletes (constraints.txt,
edx/doc.txt, edx/testing.txt -- kept deleted) and content conflicts on
the edx/{base,development}.txt compat exports (kept ours, regenerated
below).

Bumped the edx-enterprise pin from 8.7.0 to 8.7.2 in
[tool.edx_lint].uv_constraints to match master's automated bump,
regenerated constraint-dependencies via edx_lint write_uv_constraints,
re-locked (also picks up enterprise-integrated-channels 0.1.61 -> 0.1.65,
matching master), and regenerated the base.txt/development.txt compat
exports.

…rence

- static-assets-check.yml and docs/references/static-assets.rst were
  running/documenting `uv sync --group assets` (or bare `uv sync`),
  which doesn't disable `default-groups` and so installs the entire
  `default` superset (dev/test/docs/ci tooling) on top -- confirmed via
  CI logs this installed 399 packages for a job that only needs a
  handful. Scope both to `--no-default-groups` plus the specific groups
  actually needed (`assets` for building; `bundled` + `assets` for
  collectstatic, which needs the full app's installed Django apps).
  scripts/compile_sass.py's own docstring already documented and
  verified the minimal-install pattern this now matches.
- requirements/edx-sandbox/README.rst referenced a `UV_SUBPROJECTS`
  Makefile variable that doesn't exist; the sub-project loop is inline
  in the `compile-requirements` target. Corrected the cross-reference.

astral-sh/setup-uv stopped publishing floating major-version tags after
v7 -- v8.x/v9.x only exist as full semver tags. @v9 broke every job in
the previous commit ("Unable to resolve action astral-sh/setup-uv@v9,
unable to find version v9"). Corrected to @v9.0.0 everywhere.